Lennard-Jones Server

If I could write blog entries as funny as Rory Blyth, I'd be famous. Well, maybe not. I'd have to draw cartoons, too. But to really be famous, I'd have to gratutiously link to Robert Scoble. (And get him to link back to this blog, the really hard part.) (For those who have non-computer-geek lives, Scoble wrote an article on how to get your blog noticed.)

The vaguely relevant part of that last paragraph is Rory's comments about XML Dev Con 2004. Some of the talks related to Web Services.

Web Services - what are they? Zef Hemel has a good description of Service Oriented Architecture, which basically means using web services (ie, Remote Procedure Calls over port 80) to construct an application.

That leads me to the Grid, of which web services seem to be a part. (But don't get me started on the popular analogy between the power grid and the computational grid. It's seductive and appealing, and perhaps even useful at a very abstract level, but the details break down badly if you push it very far (see the Scientific American article, among others.)

The grid concept seems to encompass four different things (as far as I can tell)

1. Connecting geographically (and/or institutionally) separated supercomputers to work on a single calculation.
   
2. Harvesting idle cycles on desktop PC's
   
3. Running specific computations on remote machines (this is web services)
   
4. Running arbitrary computations on remote machines (like the recent Sun announcement, but other companies have offered similar services previously)
   

Concerning items 3 and 4, I suspect web services will be more popular then running arbitrary computations remotely. If you have enough computational or data requirements to entertain thoughts of rent-a-FLOP (or rent-a-MIP), you will care about the environment and how well the code is optimized for the target architecture (or at least how predictable the run time is). But caring about such things makes buying "generic" computing power harder, or at least more complex.

But web services are (?) about hiding those nasty details. The provider can optimize the code for the target architecture or other details, and the user need not worry. It may be useful to divide the services into two kinds, one that requires lots of data, and the other that requires lots of compuations. For data-heavy services, the provider has lots of specialized data that is updated frequently (think Google, Amazon, Ebay, or stock market info), and delivering the data + program to the user would impractical. (versus something like TurboTax, which contains lots of specialized knowledge that changes yearly, but is practical to deliver the data + program to the user's computer. Although it can be and is offered over the web as well). For computation heavy services, optimization for particular hardware, etc could be considered specialized knowledge as well (making the divisons less distinct), but I still think the division may be useful.

As a way of understanding web services, and grid concepts, I was thinking of a Lennard-Jones server. A user could request properties of a single component system interacting via a Lennard-Jones potential for a given temperture/density/system size, the server would run the simulation and return the energy,pressure, g(r), and whatever else. (It would require limits on the system size to keep from completely overloading the server).

The server could have other features, such a keeping a database of run results, and returning the simulation results nearest the requrest parameters. Although I'm not sure this would work so well if one extended the idea to more complicated systems with larger parameter space.

In some ways, it's like a database of material properties, except that the properties are all generated by computation. So the database could be improved by further computation - if the server is idle it could work on reducing errors in various quantities. Although this might wreak havoc on reproduceability for users - good versioning would be needed.